In the field of embedded signal processing systems, it is common to use breakpoints to control an execution of code using an external debug tool, whereby a breakpoint is an intentional stopping or pausing position in program code, typically positioned within the code for debugging purposes. Breakpoints provide a means of acquiring information about a program during its execution. There are two types of breakpoints that are typically supported by debug tools currently available within the industry; software and hardware breakpoints.
Hardware breakpoints can be set for instructions and data stored within both non-volatile memory (NVM) and volatile memory, but require dedicated hardware resources, for example hardware comparators and breakpoint address registers, to be provided within the embedded system. Accordingly, hardware breakpoints are typically limited in terms of the quantity of breakpoints that may be set. Due to the cost & resource impact of implementing hardware breakpoints, previous generations of microcontroller designs have typically been limited to around four hardware breakpoints being able to be set. The next generation of embedded systems are pushing the number of hardware breakpoints available to eight, at the expense of the extra hardware resources that are required.
Software breakpoints can only be set for instructions and data stored within a volatile memory. For software breakpoints, a debug tool typically replaces the instruction corresponding to the address at which the breakpoint is to be set with an instruction that alerts, say, the central processing unit (CPU) of the embedded system to the breakpoints, and, thus, the CPU (or dedicated debug hardware) is able to signal to the external debug tool. The quantity of software breakpoints is effectively unlimited, which provides an advantage over hardware breakpoints.
However, non-volatile memory, such as Flash memory, cannot readily be overwritten on an instruction level resolution without seriously impacting the application under test. For example, for some applications a breakpoint operation code may comprise, say, all ‘0’ values. For Flash architectures in which memory cells may be set to ‘0’ on say, a one-bit resolution, setting such breakpoints may be simply implemented by overwriting an instruction with a breakpoint operation code (i.e. setting all the memory cells for that instruction address to ‘0’ values. However, as is well known in the art, in order to ‘clear’ any memory cell within a Flash memory array (i.e. to reset a memory cell to a ‘1’ value for the above example), it is necessary to clear an entire flash page of memory cells, and to subsequently re-write the entire flash page back in to memory to restore any data stored within that flash page. Thus, clearing any breakpoint would require an entire flash page to be cleared and re-written.
For applications in which the breakpoint operation code comprises anything but all ‘0’ values for the above flash example, it would also be necessary to clear and re-write an entire flash page to set a breakpoint.
Another problem with setting software breakpoints within flash memory is that, if the flash memory is implemented with error correction code (ECC) functionality, overwriting an instruction within the memory with a breakpoint may cause an ECC failure. As a result, software breakpoints are typically not able to be used for NVM based code.
Significantly, the majority of embedded systems typically use ‘on-chip’ flash memory for program storage, thereby forcing the inclusion of hardware logic to implement hardware breakpoints for debugging. As such, the use of breakpoints for debugging such flash based code is inherently limited in terms of the quantity of breakpoints that may be set.
In addition, the cost in terms of hardware resources for enabling hardware breakpoints is becoming increasingly significant with the technology trend towards using multi-core systems, where a memory area is often shared between multiple processing cores (e.g. CPUs). For such multi-core systems, in order to set a breakpoint on a given address within an area of shared NVM memory, it is necessary for breakpoint hardware to be provided for each processing core.